We're finally ready to start exploring the electron API.
Now, you might have noticed that the next three sections of the course is split into individual sections
of the API.
The main process, API, the Renderer API and lastly, shared API modules.
This breakdown of different API modules is very important as trying to use an API module for the renderer.
Process won't work in the main process and vice versa, with the exception of a handful of shared modules
which, as the name implies, will work in either process.
Electron makes this very clear in its documentation also, and to get a better breakdown of which modules
belong to which process we can navigate from the electron homepage to docs.
API reference.
Where we see each and every one of the electron modules with its designated process.
Main renderer or main and Renderer, also referred to as a shed module throughout the next three API
sections, will mostly cover these individual modules in a very specific manner, meaning we won't necessarily
be building anything, but rather seeing how to use a specific module.
Having the fundamentals of the API covered this way will allow us to build real world apps incorporating
all of electronic functionality in the later sections of the course without the need to first cover
individual modules.
So with that said, let's get started with the first and most important module in the electron library,
the app instance.
Now, we've already looked at some of the very basic workings of the app.
Instant's and very importantly, this will be the only module where we won't be creating an instance
of the module in order to use it.
Electron does that for us when the app is launched and as the electron documentation states.
Then on this instance, we control our apps event lifecycle, things like quitting, the app, relaunching,
etc..
The very first of these events being the ready event here this year.
As soon as our app instance has been created and is ready for us to use at the moment, we simply pass
create window as this event callback, but to better demonstrate our change this to an anonymous callback
function.
Logging out up is ready.
After which we can call create window to create our apps browser window.
I'll start the app with that automatic main process, reloading NPM run, watch the app launches, and
if we check back in the terminal, we see that log message on.
The main process app is ready.
We can also perform a manual check on the app Instant to see if it is ready this time right in the global
scope of this main script, not waiting for the ready even to fire log out.
Checking.
Ready.
Pending app is ready.
Save, which relaunches the app, check the terminal and there before the apps really event fired,
we checked and got false.
If, however, we were to wait a couple of seconds with this check, I'll create a time out.
Logging that same message.
After two seconds, save.
Check the terminal and this time as the check was run after the app was initialized here we got through
this method of checking your app.
State can be particularly useful when working with external modules outside of this main script.
OK, so that's always going to be step one of our life cycle, knowing when it's ready equally, we
can control the end of the applications life cycle by listening for this before quitte event.
Let's see an example.
I'll get rid of this time out.
Add a new listener on the app instant's.
Listening for before quitte.
Pass a callback.
In which will logout up is quiting.
Save the app relaunches, and in the terminal we have only this app is ready message from the ready
event, but quit the app with command cue or control cue on Windows eight.
Back to the terminal.
And there we have it.
App is quitting right before Noad monologues, a clean exit, meaning the app has been terminated gracefully.
I'll just restart this.
So knowing when the app is being quit, we can go one step further and actually prevent this from happening.
Electron provides us with an event object as this callbacks first argument, I'll call it E!
And on that event, object call prevent default, the standard JavaScript method name for preventing
default event flow.
Save this.
It came on cue again and nothing, the app simply does not quit.
Check back in the terminal there preventing app from quitting.
No matter how many times I try, each attempt is stopped.
This might seem like a trivial bit of functionality, but let's say you quickly want to save a user's
work before quitting.
This would be the perfect solution.
Listen for before Quirt stop the app from quitting right the user's data to a file or database and then
proceed to manually quit the app as the user intended by calling up don't quit.
OK, before we take a look at more examples, I want to point out these platform specific notices in
the docs.
For example, this open file event, this is Mac specific as it's something you can only do on a Mac
being when you drop a file onto the application icon implying you want to launch the app with that file,
giving you the file path in order to read it or do whatever else you wish will cover platform detection
later in the course.
But it's just important to be aware of the platform restrictions throughout the docs.
I'll skip over these.
Yeah, some more cross platform events.
Let's see these window focus events, browser window blur and browser window focus.
I'll change that before forward Lessner to browser window blurr.
Logging out up unfocussed, duplicate that for browser window focus.
App focused, safe, the app relaunches, which brings it into focus, so firing the browser window
focus event and now before switching to the terminal to see that log message, noticed that in doing
so will be unfocussed, the app or blurring it, and thus expect a second log message from the browser
window blur event switch.
And there the apps browser window was focused immediately after the app initialized and then unfocussed
when we switched to the terminal back to focus unfocussed and two more logs as before these events allowing
us to know when a user moves away from our app or when a user clicks back into it, like so potentially
useful for displaying an important message.
As soon as the user engages with the app or updating some data, etc..
We have a lot of these events covering pretty much anything happening with the application, but further
down, we can also manually trigger some of these events or actions on the app.
Yeah, app instance methods I've already mentioned app don't quit in the context of preventing an app
from quitting and then quitting manually.
So let's try that.
Get rid of browser window focus.
I'll reuse this blur event.
Set a time out.
Calling up, quote.
After, say, three seconds, we could actually write this a bit nicer, passing up quite a set time
outcall back there.
So as soon as the app loses focus, wait three seconds and then could save the app launches in focus.
So click out of this main window and three seconds later gone with node reporting a clean exit as before.
We also are variants of quitte, like restarting the app or even forcing an immediate exit instead of
a graceful exit, further down we see that Israeli method we used earlier focus to manually bring the
app back into focus and some specific show and hide methods, a way to get the full path to the app
on the user's machine and very importantly, the get path method.
This is going to be our go to for knowing how to interact with the user's file system, providing us
the path to any of these common file system locations.
Let's see a couple.
I'll get rid of this Blu ray event.
And in the ready callback.
Logout up, dot get path.
For desktop, another for music.
The assigned temp directory for temporary resources the operating system can remove at will and the
all important user data directory, this path returned year should always be the default location to
store data associated with your application.
This can be anything from files, JSON data or even a simple skua like database.
Just be sure to store up resources here as that will ensure you have consistent paths without running
into permission issues or locations that don't exist.
Not to mention that electron will automatically provide the correct path for the user's operating system.
Save this.
I'll just restart this.
And they're each of those locations unique to my app with the user data path being a common Mac directory
specifically created for my app, again, an important method to know and use.
Of course, as with the event, we have many more methods, too many to cover in this one lesson, but
they are all very well documented, getting or setting your apps name, getting the current version
and so on.
You should now have a good understanding of what the app instance is used for and how to use it to its
full potential.
In the next lesson will see arguably the second most important part of the main process API, the browser
window module.